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Introduction 

• The JPSS and GOES-R programs are housed at NASA GSFC and jointly 
implemented by NASA and NOAAto NOAA requirements. NASA's role 
in the JPSS Ground System is to develop and deploy the system 
according to NOAA requirements. NASA's role in the GOES-R ground 
segment is to provide Systems Engineering expertise and oversight for 
NOAA's development and deployment of the system. 

• NASA's Earth Science Data Systems Reference Architecture is a 
document developed by NASA's Earth Science Data Systems Standards 
Process Group that describes a NASA Earth Observing Mission Ground 
system as a generic abstraction. 

• The authors work within the respective ground segment projects and 
are also separately contributors to the Reference Architecture 
document. Opinions expressed are the author's only and are not 
NOAA, NASA or the Ground Projects' official positions. 





NASA's ESDS Reference Architecture 



• Source 

- NASA's Earth Science Data Systems Working Group (ESDSWG) Standard 
Process Group (SPG) 

• "ESDS Reference Architecture for the Decadal Survey Era" 

• A data model, a set of functions and services that are common among data systems 
that operate on NASA's Earth Science data 

• Provides individuals and teams with a concrete strategy for the development and 
implementation of higher-level design. 

• Intent of the Reference Architecture 

- Establish a common "language" to describe the problem- and solution-space of 
NASA's Earth Science Data Systems 

• Approach 

- Define "Reference Architecture" and its role/usage 

- Identify Stakeholders 

- Establish basis of the problem 

- Regular vetting within NASA's ESDS community 

- Conduct a workshop, collect feedback 


JPSS Ground System Architecture 
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Reference Architecture Overview 

• Drivers 

- SPG Efforts (Identify common components, interfaces among components and standards) 

- Build a common understanding of NASA's ESDS's 

- Decadal Survey Missions 

- Interoperability momentum within NASA 

• Six High-level Use Cases (Business Use Cases) 

- Six High-level (Business Use Cases) 

• Receive Sensor Data 

• Develop Products 

• Distribute products 

• Develop Predictions 

• Manage Remote Sensor/Instrument 

• Data Stewardship 

• Views 

- Functional View 

- Information View 

- System Service View 

- Technology View 

• Mappings between views (as appropriate) 




Contrasting Polar and Geostationary 



The obvious 

- Science products similar (sensor physics, Earth physics, science) 

- Product, Spatial Extent, geometry, resolution differences. 

- Constellations are different, orbit, communications, etc. 

- Data Collection Ground Sites (polar international, versus temperate domestic) 

- Delivery of data to those sites (constant v. episodic bursty) 

- Production work flow rules similar (dependencies, triggers, timeliness) 

- Communications and computer technology (same state of art). 

Effects on Ground and Data Systems 

- Facilities divergence (sites) 

- Networking divergence, (sites, peaks) 

- Product pipeline differences (product queuing, geometric/geographic 
relationships among granules) 

- Capacities 

- Latency differences due to practical limitations and use cases 


Reference Architecture Use Cases 



The NASA ESDS reference 
architecture has identified a set of 
mission-level use cases that 
represent the common scope of all 
NASA ESDS's. 

NOAA's JPSS and GOES-R 
observatory ground data 
processing systems both share the 
ESDS use cases. 

Similarities 

Distribute products 

- GOES-R and JPSS have substantially similar customers for 
product distribution. 

Develop Predictions *(not applicable) 

- The NOAA observatory ground systems are responsible for 
reporting observations and not for developing predictions, but 
observations produced *do* feed predictions 

Manage Remote Sensor/Instrument 

- While every instrument and observatory is different the work 
flows for managing them are substantially similar between JPSS 
and GOES-R. 

Data Stewardship *(not applicable) 

- The NOAA observatory ground systems are not directly 
responsible for long-term stewardship, but rather are 
producers serving the same CLASS archive system 



Differences 

Receive Sensor Data 

- The location of ground stations and the technology for 
receipt are significantly different and require completely 
separate infrastructure and communications routing 

- Direct Broadcast and GOES Rebroadcast respectively are 
dissimilar, driving different antenna design and data use 
cases. 

Develop Products 

- While environmental products are similar, the geometry 
of observation and the streaming and queuing of raw 
data are considerably different. These differences may 
drive different optimizations within the production 
system. 


Reference Architecture Functional View 
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The Functional View is intended to 
identify those high-level functions 
that are supported by systems that 
implement the reference 
architecture. The functions 
identified within the Functional View 
are intended to be comprehensive in 
that they cover all the functions that 
a fully capable instance of the 
reference architecture will offer. 


Similarities 

The functions identified exist in both 
GOES-R and JPSS Ground systems 

- Process Level Zero Data 

- Ingest Data 

- Generate Mission Data Products 

- Monitor Mission Performance 

- Enhance Processing Algorithms 

- Archive Data 

- Distribute Data 
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Differences 

• Current JPSS and GOES-R 
implementations vary in their 
implementation details: Data format, 
metadata models, interfaces, delegation 
of functions to components, etc. 


Reference Architecture Information 
Architecture View 






• The Information Architecture View 
is intended to identify the high 
level information entities that are 
implemented within, and 
exchanged between systems that 
implement the reference 
architecture. It also defines the 
relationships between those 
information entities. 


Similarities 

• JPSS and GOES-R Ground Projects share a 
common information view. Though neither 
implements all elements, the subset of 
elements between them is similar. 

• The NOAA information architecture 
emphasizes institutional use cases that differ 
somewhat from those emphasized by NASA. In 
particular, NOAA's first-class user is the 
focused on observational application use and 
prediction systems, while NASA's is focused on 
researcher access. 



Differences 

JPSS information architecture requirements were set 
in FGDC content standard and were influenced by 
multiple agencies without a common encoding 
standard. Implementation was completed before 2005 
with design predating wide adoption of ISO standards. 

GOES-R information architecture requirements were 
fully informed by NASA EOS experience with FGDC 
content and EOS encoding; NESDIS experience with 
netCDF3, COARDS and CF conventions; and the OAIS 
reference model. Design and implementation of the 
GOES-R Metadata Model (GMM) is ongoing and 
strongly influenced by published ISO standards. 





Reference Architecture System Service View 


The System Service View of the 
ESDS Reference Architecture is 
intended to identify the key 
system-level services that are 
implemented within ESDS's. 

This representation is based on 
the Service-Oriented 
architecture pattern. 

l 

Similarities 

In general, these services are 
common between JPSS and GOES-R * 
ground systems. 

Both systems leverage other 
enterprise systems to provide 
some of the services (e.g - ESPDS 
and CLASS for access, discovery • 

and subscription) • 
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Differences: 


BroadcastData carries data at 
differing process levels, 
(observation vs. Level lb) 

GOES-R leveraging ESPDS for 
security-oriented services 

JPSS data to ESPDA through NDE 

Implementations & interfaces 



Reference Architecture Technology View 





• The Technology View of the 
ESDS Reference Architecture 
provides guidance on the role 
and selection of technologies 
and standards. [However], the 
lifecycle of technologies and 
standards is not easily 
congruent with any Reference 
Architecture. 

Similarities: 

• GOES-R and JPSS Ground systems share 
the same needs for technologies and 
standards as outlined in the reference 
architecture. 

• Generally both systems have been driven 
by the state of the art in communication 
signal processing, r/f link management, 
networking, computer hardware and 
software practices. 





Differences: 

• The two ground systems have been 
developed without specific regard 
for the choices one or the other 
has made. 

• Different standards or vendors 
were chosen based on engineering 
judgment, preferences or pricing. 






Next Steps 

• Given significant overlap in the problem-space 

— Conduct detailed analysis of the JPSS and GOES-R solutions 

• How they leverage NOAA enterprise-level services 

• Opportunities for common interfaces 

- Software and Human 

- Adaptors and/or Facades 

• Operational impacts 

- Leveraging common standards 

• Identify opportunities for new standards 




• For the evolving enterprises 

- Recommended approaches to maximize commonality 

- Isolate and clarify appropriate differences 

- Opportunities for efficiency of programs and investments 

• Provide feedback to NASA's ESDS Reference Architecture 
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